Skip to content

Add ToolTarget to bootstrap #143641

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
Open

Add ToolTarget to bootstrap #143641

wants to merge 11 commits into from

Conversation

Kobzol
Copy link
Member

@Kobzol Kobzol commented Jul 8, 2025

Oh, you thought I'm done with refactoring bootstrap tools? Na-ah, think again! After the failure of #143581, ToolTarget is back with a vengeance. This time, I implemented the test changes and tool cleanups without forcing these tools to be built with the stage0 compiler.

There are still some small wins though, LlvmBitcodeLinker now starts at stage 1, and not stage 2. Cargo should also be ported to this new mode, but I'm leaving that for a follow-up PR.

Hopefully X-th time's the charm 🤞

r? @jieyouxu

@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jul 8, 2025
@Kobzol Kobzol marked this pull request as ready for review July 9, 2025 09:46
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 9, 2025
@Kobzol
Copy link
Member Author

Kobzol commented Jul 9, 2025

#142357 was merged, so undrafting.

Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to sit on this scheme a bit, I still find it a bit confusing.

(I was reviewing this commit-by-commit, but now I realize I should've looked at the overall diff)

@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I'm on-board with the overall change, just some small nits and a double-check.

Comment on lines +904 to 915
impl LldWrapper {
/// Returns `LldWrapper` that should be **used** by the passed compiler.
pub fn for_use_by_compiler(builder: &Builder<'_>, target_compiler: Compiler) -> Self {
Self {
build_compiler: get_tool_target_compiler(
builder,
ToolTargetBuildMode::Dist(target_compiler),
),
target: target_compiler.host,
}
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion: to double-check, under dist mode, what we want to happen is

dist-tooltarget

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re. test coverage, should we explicitly add coverage for ./x build compiler/ w/ e.g. llvm-bitcode-linker under cross-compile at stage 2? Or would that be redundant? 🤔

Copy link
Member Author

@Kobzol Kobzol Jul 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is the optimal case to avoid needless rebuilds. We don't need to build lld-wrapper with stage 2, we just need to build it with an in-tree compiler (so stage 1), both to enable cross-compilation, and to ensure that we build distributed tools with in-tree code (because of stdlib security fixes and stuff).

We already have build_compiler_tools_cross, which builds the compiler with linker tools in stage 2, AND cross-compiles. I think that's enough.

@jieyouxu
Copy link
Member

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 15, 2025
@Kobzol
Copy link
Member Author

Kobzol commented Jul 15, 2025

Clarified comments.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants